Conversation
Codecov Report✅ All modified and coverable lines are covered by tests.
... and 6 files with indirect coverage changes 🚀 New features to boost your workflow:
|
volmedo
left a comment
There was a problem hiding this comment.
LGTM.
I have a general question that might not make a lot of sense in this case: are there any errors that should be treated the old way? I.e. can any of the operations on a given result fail in a way that we should be failing the whole job (as we were doing before)? I guess the answer is no, and this approach works, but maybe worth doing a quick check of the possible error conditions to confirm. If there is any specific error that should be handled differently, we can create a sentinel for that and check.
I reckon no, we should always return a result with whatever we find. The result should contain the error messages. We should however always log errors and there are certain errors that should be reported e.g. we cannot talk to redis. |
09a273d to
9d02135
Compare
When querying IPNI for location claims, the indexing service now iterates through all provider results instead of failing on the first error. This allows queries to succeed as long as at least one valid provider result exists, even if others have incomplete or invalid addresses.
See this INPI record as an example: https://cid.contact/cid/bagbaieraqcpyzx3sytzsitbdxqpahht3hw4ros5ex2jlhxe4muwcgc7d4xua
ProviderResults[1] is invalid, has only 1 address, and it is missing the location URL.
ProviderResults[0] is correct, but the indexer never finds this record.
This fixes the issue where IPNI records with missing blob retrieval endpoints (e.g., only claim URL, no blob URL) would cause the entire query to fail with a 500 error, even when other valid provider results were available.
The implementation follows the same pattern used for index claim processing, where all results are tried, and only the last error is returned if all attempts fail.